Internet protocol (“IP”) telephony and IP multimedia networks employ several protocols to setup and manage calls and sessions. One of the most widely adopted protocols for IP-based signaling is the Session Initiation Protocol (“SIP”). SIP is used, for example, for initiating new calls and sessions, manipulating call paths, and enabling the association of services with users regardless of their point of connection in the network. These are just a few areas of application of the SIP.
The increasing use of SIP has spurred development and introduction of numerous services with SIP interfaces for user and network access. This approach makes sense as the number of SIP-capable devices proliferates in IP networks. These devices have several features and mechanisms defined to employ existing telephony features in SIP.
One such feature is call-pickup. Call-pickup is a commonly used feature in today's deployed telephony solutions, especially in office environments. As an example, consider User A and User B being in a telephony conversation and User B wants to move to another location during the conversation. Suppose it is not possible to physically move the device being used by User B to the new location, and also that User B does not want to hang up the call and fully re-originate the call for any particular reason. User B may transfer the call to a device (or server) called a “park server” that temporarily holds (or “parks”) the call, allowing User B's device to disconnect without releasing the call. User B may subsequently retrieve the parked call. Therefore, User B presses a button(s) on the device that parks the call at a park server. User B then moves to the new location and retrieves the parked call by calling User A. This process of call retrieval is referred to as call-pickup.
Unfortunately, however, existing SIP-based call-pickup solutions have several drawbacks. For example, one solution requires User B to re-originate the call at the new location by sending a call-pickup origination request to User A. Therefore, in this solution, although the call will be parked in a normal fashion for User A (e.g., similar to generally accepted call park functions), User B essentially hangs up and recalls User A to park and pickup the call. One problem with this technique is that this requires advanced feature handling in a handset device so that the handset at the new location has the capability of sending detailed call-pickup origination requests. Such a feature does not exist in most of the commercially available SIP devices. Therefore, using this solution would require upgrades of most handsets in the network.
In addition, in existing solutions when picking-up the call at the new location, User B simply re-originates a call with User A, so User B must know the SIP address of User A. This may not be known if User A is calling from a payphone and does not know the phone number of the payphone or if User A is an anonymous caller, for example. Another related problem is that User A must have the capability to receive multiple calls because for a limited duration, User A will be in two calls (i.e., the call with the park server, and the call from User B from the new location). Still another related problem is that User B may incur additional charges for re-originating a call with User A from the new location. The proposed solution further assumes that from the new location, User B will have calling privileges to call User A.
Furthermore, a major problem with the proposed solution is that service providers have no control over this call-park/call-pickup feature. The park server is provided for parking the call. However, the park server is not involved in the pickup process except for being asked to disconnect the parked call because User B picks up the call by re-originating a call with User A from the new location (e.g., User B simply calls User A again from the new location). The parked call (i.e., the communication session between User A and the park server) can be dropped due to any reason (e.g., User A getting impatient and hanging up). So it is difficult for the service provider to know whether a successful call-pickup occurred. This implies that the service provider will have difficulty charging for the call-pickup feature and may have no incentive to provide this service. Therefore, the currently proposed solution is unlikely to be deployed.